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Abstract 


This  report  describes  the  development  of  a  Data  Processing  Module  (DPM) 
designed  for  use  with  an  RD  Instruments  Acoustic  Doppler  Current  Meter 
(ADCM).  The  DPM  is  a  self-powered  unit  in  its  own  pressure  case  and  its  use 
requires  no  modification  to  the  current  meter.  The  motivation  for  this  work  was 
the  desire  for  real-time  monitoring  and  data  transmission  from  am  ADCM 
deployed  at  a  remote  site.  The  DPM  serves  as  an  interface  between  the  ADCM 
and  a  satellite  telemetry  package  consisting  of  a  controller,  an  Argos  Platform 
Transmit  Terminal,  and  an  antenna.  The  DPM  accepts  the  data  stream  from  the 
ADCM,  processes  the  data,  and  sends  out  the  processed  data  upon  request  from 
the  telemetry  controller.  The  output  of  the  ADCM  is  processed  by  eliminating 
unnecessary  data,  combining  quality  control  information  into  a  small  number  of 
summary  parameters,  and  averaging  the  remaining  data  in  depth  and  time.  For 
the  implementation  described  here,  eight  data  records  of  719  bytes  each,  output 
from  the  ADCM  at  15  minute  intervals,  were  processed  and  averaged  over  2  hr 
intervals  to  produce  a  34  byte  output  array. 


Keywords:  Satellite  telemetry,  Acoustic  Doppler  Current  Profiler,  Argos. 
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1  Introduction 


1.1  Background  and  motivation 

The  desirability  of  data  telemetry  from  remote,  unmanned  sites  such  as  deep 
ocean  buoys  has  been  recognized  for  some  time,  and  several  programs  at  the 
Woods  Hole  Oceanographic  Institution  (Frye  and  Owens,  1991)  and  elsewhere 
have  helped  to  develop  this  capability.  Much  of  the  work  to  date  has  concentrated 
on  the  telemetry  of  a  limited  set  of  data  or  status  parameters,  with  little  or  no 
data  processing  or  compression.  Although  more  sophisticated  systems  are  being 
developed  (Frye  and  Owens,  1991;  Irish  et  ai,  1991),  in  some  cases  the 
telemetered  information  from  a  complex  sensor  is  only  sufficient  to  provide  an 
indication  of  instrument  status.  As  instrumentation  becomes  more  complex,  and 
as  information  from  multiple  instruments  is  combined,  the  data  rate  exceeds  that 
which  can  be  transmitted  via  conventional  means  (e.g.,  Service  Argos).  By 
developing  a  telemetry  interface  module  with  data  processing  capability,  it  is 
possible  to  recover  an  intelligently  composed  subset  of  information  from  high  data 
rate  instrumentation  systems  deployed  on  a  drifting  or  moored  platform. 

This  report  describes  the  development  of  a  Data  Processing  Module  (DPM) 
for  use  with  acoustic  Doppler  current  meters  (ADCMs).  ADCMs  produce 
prodigious  amounts  of  data  in  comparison  to  traditional  oceanographic 
instrumentation  like  the  meteorological  sensors  and  single  point  current  meters 
discussed  by  Frye  and  Owens  (1991).  During  a  deployment  where  a  high  degree  of 
temporal  and  spatial  resolution  is  required,  the  ADCM  may  generate  as  much  as  1 
Kbyte  of  data  per  min.  Internal  recording  capacity  of  up  to  40  Mbyte  allows  this 
data  to  be  archived,  but  the  low  throughput  of  satellite  telemetry  systems  like 
Argos  (approximately  1  byte/min)  make  it  impossible  to  transmit  the  complete 
data  set.  In  order  to  be  practical  for  real-time  telemetry,  the  raw  data  must  be 
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processed  to  create  a  reduced  set  of  variables  or  data  parameters  to  be 
transmitted. 

An  initial  effort  to  obtain  real-time  data  from  an  ADCM  via  satellite  was 
guided  by  McPhaden  at  the  Pacific  Marine  Environmental  Laboratory  (McPhaden 
et  aL,  1990;  1991).  The  result  was  the  PROTEUS  mooring,  consisting  of  a 
downward-looking  ADCM  mounted  in  the  bridle  of  a  surface  buoy,  and  connected 
to  a  processor  which  transmitted  averaged  velocity  profiles  at  24  hr  intervals. 
Although  benefiting  from  their  work,  we  felt  that  the  design  requirements 
(described  below)  were  different  enough  to  warrant  a  completely  independent 
implementation.  The  PROTEUS  mooring  and  the  DPM  axe  similar  in  that  both 
provide  an  interface  to  the  ADCM  and  do  some  pre-processing  of  ADCM  data  in 
preparation  for  satellite  telemetry.  The  principal  difference  is  that  on  the 
PROTEUS  mooring  one  microprocessor  handled  both  ADCM  data  processing  and 
telemetry  while  the  DPM  processes  the  data  and  offloads  it  to  an  external 
telemetry  controller.  The  design  of  the  DPM  as  a  self-contained,  addressable 
module  allows  a  telemetry  controller  to  collect  and  transmit  data  from  many 
different  sensors  by  interrogating  each  in  turn. 

The  development  of  the  DPM  was  geared  towards  a  particular  initial 
application,  an  Arctic  data  buoy.  A  recent  deployment  of  an  Arctic  Environmental 
Drifting  Buoy  (AEDB)  developed  by  S.  Honjo  of  WHOI  (Honjo  et  ai,  1990) 
demonstrated  the  feasibility  of  a  drifting  buoy  for  making  velocity  and 
temperature  measurements  below  the  Arctic  ice  pack.  The  AEDB  was  deployed  in 
August  of  1987  in  the  pack  ice  north  of  Svalbard  and  drifted  for  255  days  while 
collecting  data  on  ice  and  water  temperature,  subsurface  currents,  and  particle 
fluxe3.  Although  the  prototype  buoy  was  designed  with  telemetry  capability,  the 
data  stream  was  restricted  to  buoy  position,  temperature,  and  various  status 


parameters.  Information  from  the  sub-surface  instruments  was  not  available  until 
recovery. 

A  second-generation  Arctic  drifter,  the  Ice-Ocean  Environmental  Buoy 
(IOEB),  has  been  developed  to  succeed  the  AEDB.  The  IOEB  incorporates  a  new 
buoy  hull  design  and  a  meteorological  package  in  addition  to  sub-surface 
instrumentation  similar  to  that  deployed  on  the  original  buoy.  Plans  for  the  I0E3 
call  for  the  data  from  both  surface  and  sub-surface  sensors  to  be  made  available  to 
an  Argos  satellite  transmitter  housed  in  the  surface  floatation  element.  This 
strategy  allows  the  status  of  the  buoy  to  be  monitored  more  closely  during  the 
deployment  and  will  give  immediate  access  to  the  data  regardless  of  the  fate  of  the 
drifter.  Each  IOEB  will  carry  an  ADCM,  and  both  ADCMs  will  be  equipped  with 
a  DPM  to  allow  the  sub-surface  current  data  to  be  relayed  via  satellite  to  a  shore 
based  station  along  with  surface  meteorological  data  and  buoy  position.  The 
purpose  of  the  DPM  is  to  serve  as  the  interface  between  the  ADCM  and  an  Argos 
telemetry  system  on  the  IOEB  and  to  provide  a  manageable  subset  of  processed 
ADCM  data  for  transmission. 

1.2  Design  requirements 

The  DPM  packaging  specification  called  for  a  self-powered,  stand-alone  unit 
in  its  own  pressure  case.  In  a  typical  deployment,  the  DPM  would  be  attached  to 
ADCM  load  cage  (Fig.  1)  or  on  the  mooring  line  within  a  few  meters  of  the 
ADCM.  The  power  requirement  was  a  battery  supply  sufficient  for  deployments  of 
6  to  9  months.  Underwater  cabling  would  provide  the  communications  link 
between  the  ADCM  and  the  DPM,  and  between  the  DPM  and  a  telemetry 
controller.  The  communication  requirements  were  set  by  the  input  and  output 
devices;  the  DPM  was  designed  to  process  ADCM  data  in  a  manner  completely 
transparent  to  the  instrument  itself  (i.e.  requiring  no  modifications  to  the  ADCM) 
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and  to  communicate  with  a  generic  telemetry  controller  using  the  software  protocol 
associated  with  the  Serial  ASCII  Instrumentation  Loop  (SAIL;  IEEE,  1985). 

Prom  the  point  of  view  of  the  DPM  there  are  three  important  characteristics 
of  the  ADCM:  The  communication  protocol,  the  data  stream,  and  the  sample 
interval.  For  the  application  described  here,  the  ADCM  was  configured  to  send  a 
binary  data  stream  via  EIA-423  at  1200  baud  (8  bits,  no  parity)  every  15  minutes. 
The  ADCM  data  stream,  also  known  as  an  ensemble,  consists  of  an  average  over  a 
sequence  of  many  acoustic  pulses.  For  the  IOEB  application,  individual  pulses  are 
transmitted  once  per  second,  with  the  data  from  40  pulses  making  up  one 
ensemble.  At  the  end  of  each  ensemble  interval,  the  instrument  records  the  data 
stream  to  EPROM  memory  and  transmits  the  same  data  through  the  serial  port. 
The  sample  interval  and  serial  port  enable  are  preset;  the  instrument  sends  out  the 
data  strings  at  fixed  intervals  based  on  its  own  clock  and  cannot  be  interrogated 
through  the  serial  port  while  in  the  operational  mode.  The  serial  data  stream 
contains  a  variety  of  configuration  parameters  in  leader  and  header  arrays,  plus 
data  arrays  containing  velocity,  echo  amplitude,  and  data  quality  information  for 
each  bin  of  each  beam.  Details  of  the  characteristics  of  the  RD  Instruments 
self-contained  ADCM  are  described  in  the  manufacturer’s  documentation  (RD 
Instruments,  1991a).  A  general  familiarity  with  ADCM  technical  information, 
data  formats,  and  terminology  is  assumed  throughout  this  report. 

For  the  application  on  the  IOEB,  the  DPM  was  not  to  communicate  directly 
to  an  Argos  Platform  Transmit  Terminal  (PTT),  but  rather  to  a  telemetry  system 
consisting  of  a  controller,  PTT,  and  antenna.  The  controller  interrogates  the  DPM 
over  an  EIA-485  loop  at  9600  baud  using  the  SAIL  software  protocol  (the 
SAIL/485  implementation  is  similar  to  that  described  by  Park  et  al .,  [1991]).  Data 
requests  from  the  controller  are  made  once  per  hour.  Upon  receiving  a  valid  SAIL 
address  and  a  data  offload  command,  the  DPM  echoes  its  address  and  then  sends 


an  ASCII-Hex  data  stream  to  the  controller.  Since  the  timing  between  the 
ADCM,  the  DPM  and  the  controller  is  arbitrary,  the  DPM  must  be  able  to  service 
a  SAIL  data  request  at  any  time,  even  when  actively  communicating  with  the 
ADCM  or  processing  data. 

The  difference  in  ADCM  data  output  and  Argos  PTT  throughput  determines 
the  required  data  reduction.  The  719  byte  data  stream  and  15  min  ensemble 
interval  chosen  for  the  IOEB  implementation  give  an  effective  data  rate  of  about  3 
kbytes/hr  from  the  ADCM.  The  maximum  throughput  for  Argos  is  in  the  range  of 
60  bytes/hr,  giving  a  target  for  data  reduction  of  at  least  a  factor  of  50.  For  the 
IOEB  deployment,  a  throughput  of  only  17  bytes/hr  was  available  for  the  ADCM 
data,  so  that  data  reduction  by  about  a  factor  of  170  was  necessary.  A  set  of 
processing  routines  written  in  the  C  programming  language,  and  used  previously 
for  laboratory  analysis  of  ADCM  data,  was  implemented  on  the  DPM 
microcontroller  for  the  purpose  of  data  reduction. 

Section  two  of  this  report  provides  a  general  description  of  the  DPM,  with  the 
discussion  separated  into  sub-sections  on  hardware,  communication  and  control, 
and  software.  Four  appendices  provide  more  detailed  information  about  the  DPM 
and  its  use.  Appendix  A  describes  a  procedure  for  testing  the  DPM  in  the  lab  and 
Appendix  B  describes  the  deployment  procedure.  Appendix  C  is  a  complete 
listing  of  all  software  used  with  the  DPM.  Appendix  D  provides  technical 
information  in  the  form  of  tables  and  figures. 

2  Description  of  the  DPM 

2.1  Hardware  implementation 

The  DPM  hardware  layout  is  sketched  schematically  in  Figure  2.  The  heart 
of  the  electronics  is  an  Intel  S7C51FC  microcontroller  with  32k  of  external  RAM. 
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an  external,  opto-isolated  UART  for  EIA-423  communication  with  the  ADCM, 
and  an  EIA-232  to  EIA-485  converter  for  communication  with  a  telemetry 
controller.  A  “watchdog”  timer  circuit  implemented  in  hardware  is  used  to  reset 
the  microcontroller  in  the  event  of  firmware  or  communication  errors.  The  power 
system  consists  of  two  battery  packs  and  a  switching  regulator.  The  principal 
system  components  are  discussed  in  turn  below. 

The  Intel  87C51FC  microcontroller  was  chosen  for  the  DPM  application  for  a 
number  of  reasons,  the  most  significant  of  these  being  that  all  the  necessary 
development  tools  were  available  to  ensure  that  ‘C’  code  for  ADCM  processing, 
developed  for  mini-computers,  could  easily  be  ported  to  the  87C51.  In  the 
addition  to  this  the  controller  has  many  other  desirable  features  such  as:  low 
power  consumption,  an  idle  mode,  32  kbytes  of  internal  EPROM,  256  bytes  of 
internal  RAM,  an  internal  UART,  and  3  internal  16  bit  timers.  To  keep  power 
consumption  low,  the  microcontroller  is  clocked  by  a  2.4576  MHz  crystal  and  the 
UART  crystal  is  1.8432  MHz.  As  currently  configured,  the  DPM  uses 
approximately  23  kbytes  of  external  RAM  for  data  storage,  so  a  32  kbyte  part  was 
used.  Since  the  microprocessor  is  running  at  a  relatively  low  clock  rate,  a  150  ns, 
low  power  RAM  was  selected. 

The  external  National  Semiconductor  NSC858  UART  was  selected  because  of 
its  low  power  consumption  and  pin  controllable  power  down  mode.  In  this 
application  the  UART  is  left  powered  down  for  the  majority  of  the  time  to 
conserve  power.  The  port  is  set  up  to  receive  data  only,  and  is  shut  down  for  14 
minutes  of  the  15  minute  period  between  ADCM  sampling  intervals.  This  part 
was  abruptly  discontinued  by  National  Semiconductor  in  early  1991;  there  is  no 
pin-for-pin  compatible  replacement.  Other  similar  UARTs  are  available,  but  their 
use  would  require  both  hardware  and  software  modifications. 
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The  DPM  communicates  with  a  telemetry  controller  via  an  EIA-485  fink  tbut 
uses  SAIL  software  protocol.  This  was  accomplished  by  using  a  Maxim  US-4? 5 
transceiver  in  conjunction  with  the  miciocont roller’s  :  lternal  UART.  Tht  '  Uxim 
part  was  selected  because  of  its  very  low  power  consumption  (1.3  mW  typ.'  and 
guaranteed  EIA-4S5  performance.  This  part  on  the  DPM  is  always  enabled  ro 
that  the  module  will  respond  to  its  SAIL  address  at  any  time. 

The  watchdog  timer  circuitry  in  the  DPM  is  used  to  provide  a  power-up  re-*.-., 
pulse  and  to  reset  the  microcontroller  if  program  execution  fails.  When  power  is 
initially  applied  to  the  DPM,  pin  9  (reset)  of  the  87C51  is  held  high  for 
approximately  100  ms,  after  which  it  is  brought  abruptly  to  ground.  This  provides 
the  negative  going  edge  (after  the  supply  has  stabilized)  that  is  required  to 
properly  reset  the  microcontroller.  The  timing  for  the  watchdog  is  generated  by  a 
low  frequency  R-C  oscillator  that  is  divided  down  to  approximately  32  minutes 
(greater  than  two  sampling  periods  for  the  ADCM).  If  the  microcontroller  does 
not  regularly  reset  the  clock  divider,  indicating  a  firmware  error  condition  caused 
by  either  a  lack  of  incoming  ADCM  data  or  a  glitch  in  program  execution,  a 
power-up  reset  pulse  will  occur. 

RD  Instruments  warns  of  a  corrosion  problem  that  occurs  when  ADCMs  are 
used  with  an  external  serial  device.  To  avoid  this,  the  ADCM  data  lines  ihust  be 
electrically  isolated  from  the  external  device.  The  design  requirements  of  the 
DPM  dictated  use  of  a  micro  power  isolator  capable  of  data  rates  up  to  9600 
baud.  A  quick  look  at  readily  available  off-the-shelf  components  (their  power 
consumption  in  particular)  led  to  the  decision  to  build  an  isolator  from  discrete 
parts.  A  spectrally  matched,  high  speed  infra-red  LED  and  photo  diode  were  used 
in  conjunction  with  a  discrete  current  limiting  circuit  and  a  micro  power 
operational  amplifier  to  make  the  isolator.  Tests  showed  fhat  although  the  circuit 
could  be  made  to  operate  at  9G00  baud  data  rates,  it  was  much  more  tolerant  of 
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changes  in  the  EIA-423  levels  and  to  temperature  fluctuations  when  biased  for 
1200  baud  operation.  An  added  advantage  of  this  1200  baud  configuration  was 
that  the  isolator  performed  well  over  such  a  wide  range  of  signal  levels  that  it 
could  be  driven  directly  from  a  serial  port  on  a  PC.  Since  high  baud  rates  were 
not  required  to  handle  the  719  bytes  of  ADCM  data  at  15  minute  intervals,  the 
more  robust  and  versatile  1200  baud  configuration  was  implemented. 

The  DPM  is  equipped  with  two,  7  “D”  cell  alkaline  battery  packs.  This 
provides  a  nominal  10.5  V  source  with  a  28  ampere-hour  capacity.  De-rating  the 
batteries  to  66%  of  capacity  to  accommodate  their  degradation  at  low 
temperatures  and  to  allow  for  some  safety  factor  leaves  the  DPM  with  a  working 
capacity  of  18.5  ampere-hours.  Design  goals  were  to  provide  the  DPM  with  a 
service  life  expectancy  of  approximately  9  months  given  the  duty  cycle 
appropriate  for  the  IOEB  deployment. 

The  function  of  the  voltage  regulator  is  io  convert  the  battery  voltage  to  a 
constant  5  volt  supply  for  the  DPM.  The  Maxim  MAX638EPA  switching 
regulator  was  chosen  for  its  high  conversion  efficiency  and  small  size  (low 
associated  parts  count).  Bench  tests  showed  that  the  configuration  used  in  the 
DPM  would  function  at  75%  to  92%  efficiency  over  the  full  range  of  expected 
operating  conditions.  The  wide  range  of  efficiency  is  due  to  load  conditions  that 
vary  from  2-30  mA,  and  from  an  input  (battery)  voltage  range  that  varies  from 
11-6.5  V  (6.5  is  the  minimum  input  voltage  allowed  for  regulator  operation). 

2.2  Communication  and  control 

The  DPM  communicates  serially  with  the  ADCM  over  an  optically  isolated 
EIA-423  link  and  with  a  telemetry  controller  via  EIA-485.  The  1200  baud 
EIA-423  communications  link  is  accomplished  in  the  DPM  by  an  NSCS58  UART 
which  provides  a  data  ready  pulse  to  the  87C51  microcontroller’s  external 


interrupt  1  pin.  The  87C51  on-chip  serial  port  services  the  9600  baud  EIA-485 
communication  link.  Both  channels  use  8  and  no  parity. 

A  flow  chart  of  DPM  communication  and  control  is  shown  in  Figure  3.  The 
DPM  is  initially  powered  up  by  use  of  an  external  control  line  (a  shorting  plug)  or 
may  experience  a  power-up  reset  due  to  the  watchdog  timer.  In  normal  operation 
the  DPM  resets  the  watchdog  timer  every  15  minutes,  after  receipt  of  each 
ensemble  from  the  ADCM.  This  prevents  the  timer  from  reaching  its  32  minute 
trigger.  In  the  event  that  the  timer  is  not  reset  during  a  32  minute  period,  the 
watchdog  circuit  will  provide  a  pulse  to  reset  the  DPM.  Upon  reset,  the  DPM 
restarts  the  firmware,  reinitializing  all  variables  and  zeroing  the  output  buffers. 
Thus,  a  data  stream  of  all  zeros  from  the  DPM  in  response  to  a  SAIL  query 
indicates  that  a  reset  has  occurred. 

In  order  to  save  power,  the  87C51FC  microcontroller  is  put  into  a  low  power 
idle  mode  whenever  it  is  not  processing  data  or  servicing  serial,  external  or  timer 
interrupts.  The  microcontroller  exits  idle  mode  when  it  receives  an  interrupt,  so 
the  telemetry  controller  can  address  the  DPM  over  the  EIA-485  link  at  tiny  time. 
The  NSC858  UART  is  turned  off  by  the  microcontroller  directly  after  receipt  of  a 
complete  719  byte  ensemble  from  the  ADCM.  While  it  is  off,  characters  sent  by 
the  ADCM  would  not  trigger  an  external  interrupt  and  therefore  not  be  received 
by  the  DPM.  However,  the  UART  is  turned  back  on  14  minutes  after  it  is  turned 
off,  in  response  to  the  microcontroller’s  internal  timer  1  interrupt  routine.  Since 
ensembles  are  sent  every  15  minutes  by  the  ADCM,  all  of  the  ADCM  data  is 
received. 

A  communications  interrupt  may  be  either  the  EIA-423  data  stream  from  the 
ADCM  or  an  EIA-485  SAIL  command  from  a  telemetry  controller.  If  incoming 
ADCM  data  has  the  proper  character  count  (719  bytes),  it  is  sent  to  an 
“unpacking”  routine  wh_rc  the  packed  binary  data  stream  is  decoded.  An 
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incomplete  ensemble  (at  least  1  byte,  but  less  than  719  bytes)  causes  a  timeout  in 
the  communications  routine  and  is  counted  as  a  bad  ensemble.  Ensembles  sent  to 
the  unpacking  routine  which  do  not  have  the  correct  checksum,  or  do  not  contain 
the  expected  header  values,  are  rejected  and  counted  as  bad  ensembles. 

Otherwise,  the  “good  ensemble”  counter  is  incremented  and  the  data  is  stored  for 
later  processing. 

When  the  total  number  of  ensembles  received  (the  sum  of  the  good  and  bad 
ensemble  counters)  equals  eight,  representing  two  hours  of  data  from  the  ADCM, 
the  DPM  processes  the  data  and  stores  a  68  character  ASCII-Hex  data  array  in 
one  of  two  output  buffers  for  transmission  to  the  telemetry  controller.  The  double 
buffering  scheme  is  used  to  ensure  that  an  existing  output  array,  which  has  not  yet 
been  sent  to  the  controller,  will  not  be  corrupted  by  newly  processed  data.  Within 
each  buffer  the  output  array  is  arranged  in  two  halves,  an  “even  half”  containing 
data  for  the  even  depth  bins  of  the  ADCM  profile,  and  an  “odd  half”  containing 
data  for  the  odd  depth  bins  (the  details  of  the  output  array  contents  are  discussed 
in  Section  2.3). 

Two  telemetry  controllers,  with  independent  PTTs  and  Argos  antennae,  are 
used  on  the  IOEB  to  provide  a  robust  data  transmission  scheme.  Each  controller 
interrogates  the  DPM  at  2  hour  intervals,  but  their  timing  is  staggered  so  that  the 
DPM  receives  a  request  for  data  approximately  once  per  hour.  A  SAIL  data 
request  consists  of  an  attention  character  (#),  a  two  character  address,  and  a  data 
offload  command  (R).  The  DPM  responds  to  a  data  request  with  an  echo  of  the 
address  and  offload  command  followed  by  34  ASCII-Hex  characters  of  data  from 
the  most  recently  filled  output  buffer.  The  two  controllers  use  different  addresses 
(40  and  41)  to  interrogate  the  DPM.  The  DPM  considers  either  of  the  two 
addresses  valid,  sending  the  even  half  of  the  output  array  in  response  to  a  data 
request  which  uses  the  even  address  (#40R)  and  the  odd  half  in  response  to  one 
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which  uses  the  odd  address  (#41R).  Thus,  transmission  of  the  full  DPM  output 
array  is  split  over  two  independent  telemetry  systems.  The  data  in  the  two  halves 
of  the  output  array  are  arranged  so  that  either  half  alone  provides  useful 
information. 

2.3  Data  processing 

The  DPM  processing  routines  were  developed  from  programs  used  to  analyze 
ADCM  data  from  the  Arctic  Environmental  Drifting  Buoy  deployment 
(Plueddemann,  1991).  There  are  two  principal  processing  tasks,  “unpacking”  the 
binary  ADCM  data  stream  for  each  ensemble  and  reducing  the  data  after  eight 
ensembles  have  been  unpacked.  For  the  IOEB  application  the  ADCM  data  stream 
is  719  bytes  long  and  contains  a  header  and  leader,  plus  velocity,  echo  intensity, 
percent  good,  and  status  information  for  each  beam  (Fig.  4).  Spectral  width  is 
not  recorded.  The  unpacking  step  consists  of  decoding  the  packed  binary  ADCM 
data  stream  and  filling  a  floating  point  array  with  the  decoded,  scaled  data.  The 
majority  of  the  data  reduction  is  accomplished  by  eliminating  non-essential  data 
and  averaging  the  remaining  data  in  depth  and  time.  Some  additional  benefit  is 
gained  from  the  creation  of  summary  error  and  status  parameters  and  judicious 
scaling  based  on  expected  data  values. 

Upon  receiving  a  719  byte  ensemble  from  the  ADCM,  the  controlling  program 
passes  the  array  to  the  unpacking  routine.  The  first  step  in  the  unpacking  routine 
is  to  compute  the  checksum  for  the  complete  ensemble  and  decode  the  header. 

The  checksum  computed  in  the  unpack  routine  is  compared  to  the  checksum  sent 
with  the  ensemble.  The  size  of  each  of  the  data  arrays  is  extracted  from  the 
header  (Fig.  5)  and  checked  against  the  expected  array  sizes.  Any  errors  found 
during  these  checks  result  in  a  flag  being  set  to  indicate  a  communication  error. 
The  associated  data  ensemble  is  counted  as  a  “bad  ensemble",  it  is  not  stored  and 
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will  not  be  included  in  the  averaging  step.  Ensembles  which  pass  these  checks  are 
processed  further;  the  leader  data  (Fig.  6)  is  extracted  and  stored  (except  for  the 
CTD  and  bottom  track  variables,  since  these  functions  are  not  used),  and  the  four 
data  arrays  are  decoded  and  stored. 

After  eight  ADCM  ensembles  have  been  received,  the  controlling  program 
calls  a  sequence  of  routines  that  perform  several  processing  steps  along  with  error 
checking  and  averaging.  The  first  processing  step  is  to  document  the  status  of 
ADCM  operation  using  information  from  the  leader  and  the  percent  good  array. 
The  Built  In  Test  (BIT  status;  RDI,  1991a)  code  from  the  leader  is  used  to  set 
two  flags,  one  for  beam  frequency  errors  and  one  for  transmitter  current  errors. 
The  percent  good  information  is  combined  into  a  single  good/no-good  status  bit 
for  each  averaged  bin.  Data  in  a  given  bin  is  generally  considered  to  be  of  poor 
quality  if  the  percent  good  value  is  less  than  25.  The  status  bit  is  set  if  percent 
good  values  less  than  25  occur  in  more  than  ten  percent  of  the  samples  in  the 
depth-time  averaging  interval. 

The  next  processing  step  is  time  averaging  of  the  leader  data.  This  consists  of 
a  simple  arithmetic  average  over  the  number  of  unpacked  ensembles  in  the  storage 
arrays.  Under  normal  conditions  S  ensembles  will  have  been  unpacked  and  stored 
at  the  end  of  a  two  hour  period.  If  communication  errors  have  occurred,  there 
may  be  fewer  than  8  ensembles  to  process.  There  are  14  leader  values  included  in 
the  averaging  step:  time  in  decimal  days,  number  of  ADCM  bins,  ensemble 
number,  BIT  status,  x-axis  tilt,  y-axis  tilt,  heading,  temperature,  high  voltage 
level,  transmit  current  level,  low  voltage  level,  and  the  standard  deviations  of 
x-tilt,  y-tilt,  and  heading. 

The  major  processing  task  involves  manipulation  of  the  velocity  and  echo 
amplitude  data,  recorded  by  the  ADCM  in  beam  coordinates,  to  produce 
depth-time  averaged  arrays  in  earth  coordinates.  For  the  10EB  application  a  16  m 


12 


transmit  pulse  was  used  and  40  eight-meter  bins  were  recorded.  Note  that  since 
the  transmit  pulse  sets  the  fundamental  vertical  resolution  of  the  measurements, 
the  eight  meter  bins  represent  oversampling  by  a  factor  of  two.  The  depth 
averaging  implemented  for  the  IOEB  deployment  is  a  three  bin  average  of  the  first 
30  bins,  resulting  in  10  averaged  bins.  Time  averaging  is  over  the  2  hr  interval 
represented  by  the  sequence  of  8  ensembles.  Before  the  averaging  step,  however, 
several  other  processing  tasks  are  executed.  First,  the  tilt  data  is  used  to 
interpolate  the  slant  velocity  and  echo  amplitude  for  each  beam  onto  standard 
depths.  Next,  the  four  beams  cf  slant  velocity  are  combined  into  two  horizontal 
velocities  and  two  vertical  velocity  estimates.  The  heading  data  is  used  to  rotate 
the  horizontal  velocities  into  earth  coordinates.  The  mean  of  tne  two  vertical 
velocities  and  the  mean  of  the  four  beams  of  echo  amplitude  are  computed  during 
the  averaging.  Thus,  the  output  of  this  processing  step  is  4  ten-bin  arrays 
containing  depth-time  averaged  values  of  east  velocity,  north  velocity,  vertical 
velocity,  and  echo  amplitude. 

'  The  final  step  in  the  processing  is  to  pack  the  status  flags  plus  the  averaged 
leader  and  velocity  data  into  an  output  buffer  for  transmission  to  a  telemetry 
controller.  As  discussed  above,  there  are  two  telemetry  controllers  on  the  IOEB 
which  request  data  from  the  DPM  using  two  different  SAIL  addresses.  Between 
the  two  controllers  the  DPM  is  interrogated  once  per  hour  and  the  full  output 
array,  representing  a  two  hour  average,  is  sent  in  two  halves.  It  was  decided  that 
the  hourly  transmissions  would  consist  of  a  header  plus  status  and  velocity  data 
for  half  of  the  depth  bins.  The  header  is  repeated  for  each  transmission,  but 
alternating  even  and  odd  depth  bins  are  sent  in  response  to  the  alternating  SAIL 
addresses.  A  combination  of  a  count  bit  which  alternates  between  0  and  1,  and  an 
even  (0)  and  odd  (1)  bin  flag  are  used  to  keep  track  of  what  has  been  sent 
(i.e. ,  four  successive  transmissions  would  have  a  [count,  even/odd  bin]  sequence  of 


[0,0]  [0,1]  [1,0]  [1,1]).  This  information  is  useful  for  putting  the  half-arrays  back 
together  in  the  proper  order,  particularly  if  occasional  transmissions  are  missed. 
The  repeated  header  and  alternating  even-odd  bin  sequence  is  similar  to  the 
scheme  described  by  McPhaden  et  al.  (1900)  and  ensures  that  usable  data 
spanning  the  desired  depths  (albeit  with  poorer  resolution)  will  be  received  even  if 
one  of  the  telemetry  systems  malfunctions. 

Due  to  the  limited  space  (135  bits)  allotted  to  the  ADCM  for  each  hourly 
transmission  from  the  IOEB  (Fig.  7),  the  averaged  data  had  to  be  reduced  further 
before  going  into  the  output  buffer.  This  was  accomplished  by  choosing  not  to 
transmit  the  echo  amplitude  array  and  restricting  the  output  header  to  a  subset  of 
the  averaged  leader  data.  The  floating  point  horizontal  velocity  data  is  seeded  and 
converted  into  S-bit  integers,  the  vertical  velocity  into  4-bits.  The  first  half  of  the 
272  bit  output  array  (Fig.  8)  consists  of  a  dummy  bit,  count  bit,  even/odd  bin  bit, 
even-bin  status  array  (5  bits),  error  flag  array  (4  bits),  temperature  (8  bits), 
number  of  ensembles  in  the  average  (4  bits),  tilt  standard  deviation  (6  bits), 
heading  standard  deviation  (6  bits),  even-bin  east  velocity  array  (40  bits),  even-bin 
north  velocity  (40  bits),  and  even-bin  vertical  velocity  (20  bits).  The  second  half 
of  the  output  array  (Fig.  8)  contains  the  same  count  bit,  the  opposite  even/odd 
bin  bit,  the  same  error,  temperature,  ensemble,  and  instrument  motion  data,  and 
the  odd-bin  status,  east  velocity,  north  velocity,  and  vertical  velocity  arrays. 

The  output  data  is  packed  into  an  ASCII-Hex  array  with  two  characters  per 
8-bit  word.  Thus,  it  takes  272  bits  to  store  the  68  ASCII-Hex  characters.  A 
pointer,  set  by  examining  the  incoming  SAIL  address,  determines  whether  the 
even  or  odd  half  of  the  buffer  will  be  sent  to  the  telemetry  controller  each  hour. 
Upon  receipt  by  the  controller,  the  34  ASCII- Hex  characters  are  unpacked,  the 
dummy  bit  is  eliminated,  and  the  remaining  135  bits  are  added  to  the  data  stream 
for  the  appropriate  PTT  (Fig  7). 
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Appendices 

A.  Test  procedure 

A  test  procedure  meant  to  be  used  in  verifying  the  operation  of  the  DFM 
prior  to  field  deployment  is  described  below.  Two  IBM  compatible  PCs,  an 
ammeter,  and  various  test  cables  are  necessary  for  the  complete  test  (Fig.  9).  The 
ammeter  replaces  the  DPM  shorting  plug  and  is  used  to  check  current  draw  by  the 
UART  and  microcontroller.  The  procedure  can  be  performed  without  the 
ammeter  if  current  checks  are  not  desired.  The  PCs  simulate  the  ADCM  and 
telemetry  controller.  The  result  of  the  test  is  a  sequence  of  DPM  output  records 
which  can  be  compared  to  a  file  containing  the  expected  output.  A  RMK-7  to 
DB-25  test  cable  is  needed  to  connect  the  EIA-423  side  of  the  DPM  to  the  PC 
simulating  the  ADCM.  A  program  called  OVERNITE.C  (see  Appendix  C)  is  run 
on  this  PC  to  send  simulated  ADCM  data  transmissions  to  the  DPM.  The 
program  accesses  a  data  file  called  DPMCCS6.BIN  containing  a  sequence  of 
previously  recorded  ADCM  binary  data  ensembles  which  have  been  modified  to 
test  a  variety  of  DPM  features.  A  RMG-3BCL  connector  and  cable  are  used  to 
connect  the  EIA-4S5  side  of  the  DPM  to  an  Acromag  EIA-485  to  EIA-232 
converter  box.  A  second  cable  with  two  DB-25  connectors  attaches  the  Acromag 
box  to  the  serial  port  (C0M1)  of  the  PC  simulating  the  telemetry  controller.  This 
PC  runs  a  program  called  TT.C  (see  Appendix  C)  which  requests  processed  data 
records  from  the  DPM  using  SAIL  commands. 

The  VSG-2BCL  connector  on  the  top  end  cap  of  the  DPM  is  used  to  power 
the  module.  A  dummy  plug  is  used  to  cover  this  connector  when  the  DPM  is  not 
in  use.  The  RED  color-coded  shorting  plug  turns  the  DPM  on  by  connecting  the 
10.5  VDC  battery  packs  in  the  DPM  to  the  input  of  the  switching  regulator.  After 
making  the  initial  connection  with  an  ammeter  in  place  of  the  shorting  plug,  the 
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DPM  should  settle  out,  within  20  seconds,  to  a  current  drain  of  2.3  mA  ±  0.3  mA. 
At  this  point  the  DPM  UART  is  on  and  waiting  for  data.  The  DPM  will  stay  in 
this  state  until  it  receives  a  serial  stream  from  the  ADCM  (or  equivalent 
simulation).  The  ADCM  serial  data  enters  the  DPM  via  the  XSK-7BCL 
connector.  The  XSG-3BCL  connector  is  the  EIA-485  connection  between  the 
DPM  and  the  telemetry  controller  or  controller  simulator. 

ADCM  operation  is  simulated  by  connecting  the  RMK-7  to  DB-25  test  cable 
from  the  DPM  to  the  serial  port  (COM1)  of  a  PC  and  running  the  test  program 
OVERNITE.C.  The  test  program  will  ask  for  a  data  file  to  use  as  input.  The  file 
DPMCCS6.BIN  should  be  available  in  the  same  directory  as  OVERNITE.C  and 
should  be  specified  as  the  input  file.  The  number  of  ensembles  should  be  set  to 
144  and  the  time  between  ensembles  to  15  minutes.  If  a  mistake  is  made  in 
specifying  input  parameters  for  OVERNITE.C,  reboot  the  computer,  reset  the 
DPM  by  removing  and  re-connecting  the  shorting  plug  (or  ammeter  connection), 
and  start  again.  When  OVERNITE.C  is  running  successfully,  a  message  will  be 
sent  to  the  screen  as  each  simulated  ADCM  data  ensemble  is  sent. 

Immediately  after  receiving  a  valid  ADCM  data  ensemble,  the  current  draw 
from  the  DPM  will  rise  to  5.5  mA  ±  0.5  mA  for  a  few  seconds  while  the  DPM 
unpacks  and  stores  the  data  in  RAM.  After  receiving  and  unpacking  the  data,  the 
DPM  goes  into  an  idle  mode  in  which  it  will  respond  to  EIA-485  SAIL  requests 
from  the  telemetry  controller,  but  will  not  accept  data  from  the  ADCM.  The 
NSC858  UART  is  powered  down  in  this  state  and  the  microcontroller  is  idle.  The 
current  drawn  by  the  DPM  will  drop  to  1.2  mA  ±  0.3  mA.  The  idle  mode  will 
continue  for  14  minutes  after  which  the  UART  is  turned  back  on  and  the  DPM  is 
ready  and  waiting  for  EIA-423  data  from  the  ADCM.  The  current  level  will 
increase  back  to  the  original  2.3  mA  ±  0.3  mA  until  another  valid  ADCM 
ensemble  is  received  and  the  data  collection  cycle  begins  again.  This  cycle  will 
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continue  unless  data  is  not  received  from  the  DPM  at  the  expected  15  minute 
interval  (e.g.,  the  ADCM  is  disconnected  or  inoperative  and  data  transmissions 
stop).  If  no  ADCM  ensembles  are  received,  the  DPM  will  wait  in  the  ready  state 
(NSC858  UART  on)  for  EIA-423  data  and  the  microprocessor  will  be  reset  every 
32  minutes  by  the  watchdog  timer. 

Any  time  after  the  DPM  is  turned  on  (using  the  shorting  plug  or  an  ammeter 
in  place  of  the  shorting  plug),  the  module  can  be  addressed  via  EIA-485  SAIL 
commands.  A  50  foot  test  cable  with  a  RMG-3BCL  connector  on  one  end  is 
provided  for  this  purpose.  The  other  end  of  the  cable  should  be  connected  to  an 
Acromag  485/232  converter  box.  The  EIA-232  side  of  the  Acromag  box  is  then 
connected  to  the  serial  port  (COMl)  of  a  PC  running  the  telemetry  controller 
simulation  program  TT.C.  (Note  that  TT.C  is  not  necessary  for  a  simple 
simulation  of  the  telemetry  controller  —  a  terminal  emulation  program  running  on 
the  PC  with  serial  communication  settings  of  9600  baud,  no  parity,  8  data  bits,  1 
stop  bit  can  be  used  to  send  SAIL  commands  by  hand).  It  should  be  started  at 
least  5  minutes,  but  less  than  15  minutes  after  OVERNIGHT. C  for  proper  results. 
The  TT.C  program  will  request  a  data  file  name  to  which  it  will  log  the  DPM 
responses.  TT.C  will  send  the  first  command  (without  the  attention  character  #) 
to  the  DPM  within  a  minute  after  the  interrogation  loop  is  started  by  selecting  a 
transmission  interval.  An  interval  of  60  minutes  should  be  selected.  The  DPM  will 
respond  to  the  SAIL  data  offload  commands  #40R  and  #41R  with  an  echo  of  the 
command  (without  the  attention  character  #)  followed  by  34  characters  of  data 
and  an  ETX  (ASCII  03)  to  end  the  transmission.  The  data  will  be  all  zero;  until 
eight  ensembles  have  been  received  and  processed.  The  receipt  of  eight  ensembles 
will  take  two  hours  from  the  time  of  the  first  ADCM  ensemble.  Since  the  DPM 
output  array  is  in  two  halves,  transmitted  once  per  hour,  the  response  to  the  first 
two  SAIL  requests  will  contain  zeros. 
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The  processing  steps  initiated  upon  receipt  of  the  8th  ADCM  ensemble  take 
approximately  four  minutes  to  complete.  During  this  time  the  current  drain  at  the 
DPM  will  be  6  mA  ±  0.5  mA.  Once  the  first  set  of  eight  ensembles  has  been 
processed,  the  DPM  will  respond  to  the  SAIL  offload  commands  by  sending  the 
processed  data.  If  at  any  time  after  this  the  DPM  responds  to  a  data  request  with 
a  string  of  zeros,  it  is  an  indication  that  the  microprocessor  has  been  reset  by  the 
watchdog  timer.  A  listing  of  the  expected  DPM  output  when  using  the  simulated 
ADCM  ensembles  in  the  file  DPMCCS6.BIN  is  given  in  Figure  10  and  in  the  file 
DPMCCS6.0UT.  The  contents  of  the  file  created  by  TT.C  during  the  test 
procedure  should  be  compared  to  this  listing. 

B.  Deployment  procedure 

1.  The  ADCM  and  DPM  should  be  installed  in  the  load  cage  (see  Fig.  1)  and 
the  cable  from  the  telemetry  controller  should  be  accessible  at  the  location 
of  the  DPM. 

2.  Download  the  desired  configuration  parameters  to  the  ADCM  using  the 
Deployment  Configuration  Files  provided  (e.g.,  1198. DPF)  and  the  RD 
Instruments  Deployment  Program  (RD  Instruments,  1991b).  Upon 
completion  of  the  deployment  procedure,  the  ADCM  will  be  running  and 
sending  serial  data  every  15  minutes.  The  first  ensemble  will  be  sent 
immediately  following  the  last  entry  in  the  deployment  sequence.  Since  the 
DPM  is  not  connected  at  this  time,  the  first  ensemble  received  by  the  DPM 
will  be  15  minutes  later. 

3.  Remove  the  three  dummy  plugs  from  the  DPM  and  store  them  in  the 
packing  crate.  Locate  the  RED  color-coded  shorting  plug  in  the  packing 
crate.  Attach  the  DPM  XSK-7BCL  connector  to  the  ADCM  XSL-20BCR 


I/O  connector  using  the  two  meter  RMK-7FS  to  XSL-20CCP  cable  packed 
with  the  DPM.  Attach  the  DPM  XSG-3BCL  connector  to  the  telemetry 
controller  cable. 

4.  Power  up  and  reset  the  DPM  by  connecting  the  RED  color-coded  shorting 
plug  to  the  VSG-2BCL  connector  on  the  end  cap.  The  DPM  will  now  be 
running  and  waiting  for  the  next  ensemble  from  the  ADCM.  Note  that  the 
first  ensemble  will  not  have  been  received  by  the  DPM  (see  (2)),  but  it  is 
assumed  that  (3)  and  (4)  are  completed  within  15  min  of  starting  the 
ADCM,  so  that  the  second  ensemble  will  be  received. 

5.  The  DPM  can  be  interrogated  by  the  telemetry  controller  at  any  time  after 
power-up.  The  first  non-zero  data  array  from  the  DPM  will  be  obtained  after 
receipt  and  processing  of  eight  ADCM  ensembles,  or  2  hrs  after  receipt  of 
the  first  ensemble.  Since  the  first  ADCM  record  is  not  received  by  the  DPM, 
this  will  occur  approximately  2  hrs  15  min  after  start-up  of  the  ADCM. 

C.  Program  listings 

Four  C-language  programs  associated  with  the  use  of  the  DPM  are  listed  on 
the  following  pages. 

DFM.C  is  the  main  communication  and  processing  program,  written  in 
Franklin  C,  which  runs  on  the  Intel  87C51FC  microcontroller  in  the  DPM.  The 
compiler  used  was  Franklin  C,  version  3.07,  the  assembler  was  Franklin  Assembler 
version  4.4,  and  the  linker  was  Franklin  Linker  Lol,  version  2.7.  A  companion 
program,  PCJDPM.C,  was  written  in  Microsoft  Quick-C  and  run  on  an  IBM 
compatible  PC.  PCJDPM  processes  data  in  the  same  fashion  as  DPM.C,  but  reads 
from  and  writes  to  disk  files  on  the  PC  rather  than  communicating  to  the  ADCM 
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or  the  telemetry  controller.  This  version  was  used  during  development  and  testing, 
but  is  not  reproduced  here. 

OVERNITE.C  and  TT.C  are  used  in  the  deployment  simulation  procedure 
and  allow  the  DPM  to  be  exercised  in  the  absence  of  the  other  instrumentation  to 
be  used  in  the  deployment.  OVERNITE.C  simulates  the  operation  of  the  ADCM 
by  taking  a  file  of  binary  ADCM  data  and  sending  it  serially  to  the  DPM  at  a  user 
specified  interval.  TT.C  simulates  the  telemetry  controller  by  sending  alternating 
SAIL  data  offload  commands  (#40R  and  #41R)  to  the  DPM  at  an  adjustable 
interval.  The  data  received  in  response  is  stored  in  a  file  and  printed  to  the  screen. 

DPMSATOUT.C  unpacks  the  output  data  array  sent  to  the  telemetry 
controller,  and  was  used  during  development  and  testing  of  the  DPM.  The 
program  takes  groups  of  34  ASCII  hex  characters  representing  alternating  halves 
of  the  output  data  array,  combines  the  appropriate  pairs,  and  then  decodes  the 
data. 
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D.  Technical  information 


The  layout  of  the  principal  DPM  board  components,  including  the  specially 
made  DPM  component  carriers,  is  shown  in  Figure  11.  The  DPM  board  schematic 
is  shown  in  Figure  12.  DPM  mechanical  and  electrical  specifications  are  provided 
in  Table  1-.  Connector  specifications  for  the  DPM  and  cable  specifications  for  the 
DPM  to  ADCM  interconnection  are  given  in  Table  2.  A  parts  list  is  provided  in 
Table  3. 
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Figure  1:  The  Data  Processing  Module  (DPM)  is  a  self-powered  unit  in  its  own  pres¬ 
sure  case  designed  to  be  deployed  along  with  an  RD  Instruments  Acoustic  Doppler 
Current  Meter  (ADCM).  The  figure  shows  a  typical  deployment  configuration  with 
the  DPM  clamped  onto  the  ADCM  load  cage.  Inside  the  DPM  pressure  case  is  a 
single-board  electronics  package  and  two  battery  packs  (inset).  The  DPM  serves  as 
an  interface  between  the  ADCM  and  a  satellite  telemetry  controller. 
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Figure  2:  A  block  diagram  of  the  principal  DPM  hardware  components  is  shown. 
The  power  system  consists  of  two  battery  packs  and  a  switching  regulator.  The  heart 
of  the  electronics  is  an  Intel  87C51FC  microcontroller  with  an  onboard  UART,  256 
bytes  of  RAM,  32  kbytes  of  EPROM,  and  three  16-bit  timers.  Additional  memory 
is  provided  by  an  external  32  kbyte  RAM  chip.  The  onboard  UART  is  used  for 
EIA-485  communications  to  the  telemetry  controller  while  an  external  UART  talks 
to  the  ADCM  through  an  opto-isolator.  A  watchdog  timer  circuit  is  used  to  reset: 
the  microcontroller  in  the  event  of  software  or  communication  errors. 
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Figure  3:  The  main  control  loops  of  the  DPM  processing  program  and  the  response 
to  communication  interrupts  are  shown  in  a  flow  chart.  After  initialization,  the 
DPM  waits  for  either  an  EIA-4S5  interrupt  from  the  telemetry  controller  or  an 
EIA-423  interrupt  from  the  ADCM.  A  SAIL  data  offload  command  received  on  the 
EIA-485  channel  initiates  the  data  offload  sequence.  A  valid  data  stream  received 
through  the  EIA-423  channel  initiates  the  processing  sequence.  DPM  communica¬ 
tion  and  control  are  described  in  more  detail  in  the  text. 
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Figure  4:  A  schematic  diagram  shows  the  packed  binary  data  stream  transmit¬ 
ted  through  the  ADCM  serial  I/O  connector  for  each  ensemble.  The  data  stream 
consists  of  a  header,  a  leader,  up  to  four  data  arrays,  and  a  checksum.  For  the  im¬ 
plementation  of  the  DPM  on  the  Ice-Ocean  Environmental  Buoy  (IOEB),  the  data 
stream  is  719  bytes  long  and  the  data  arrays  selected  are  velocity,  echo  intensity, 
percent  good,  and  status.  The  DPM  decodes  the  variables  from  each  ensemble  and 
stores  them  in  RAM.  After  eight  ensembles  have  been  accumulated,  the  processing 
sequence  is  initiated. 
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Figure  5:  The  contents  of  the  ADCM  header  are  shown.  The  data  array  sizes 
transmitted  in  the  header  are  compared  to  the  expected  array  sizes  based  on  the 
ADCM  configuration.  Since  the  array  sizes  are  fixed  after  the  initial  configuration, 
this  comparison  serves  as  a  check  of  the  integrity  of  the  incoming  data  stream. 
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Figure  6:  The  contents  of  the  ADCM  leader  are  shown.  All  leader  data  except  that 
related  to  CTD  sampling  and  bottom  tracking  (neither  of  which  are  implemented) 
are  decoded  and  stored  in  RAM.  Some  data  (e.g.,  number  of  bins,  BIT  status) 
are  used  in  error  checking.  Other  data  (e.g.,  heading  and  tilt)  are  used  during 
processing. 
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Figure  7:  The  transmission  scheme  for  the  IOEB  Argos  telemetry  system  is  shown. 
Two  PTTs  are  used  to  transmit  data  from  various  sensors.  The  two  PTT  controllers, 
each  using  a  different  SAIL  address,  interrogate  the  DPM  at  two  hour  intervals  to 
request  ADCM  data.  The  DPM  sends  the  even-bin  data  in  response  to  one  of  the 
SAIL  addresses,  and  the  odd-bin  data  in  response  to  the  other.  Since  the  two-hour 
PTT  transmission  intervals  are  staggered  by  one  hour,  the  DPM  is  interrogated 
twice  over  a  two  hour  interval  (once  by  each  PTT)  and  the  full  output  array  is 
transmitted  in  two  halves. 
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Figure  8:  The  contents  of  the  DPM  output  array  are  shown.  The  output  array 
is  sent  in  two  136  bit  halves  in  response  to  interrogation  by  two  different  PTT 
controllers  (see  Fig.  7).  The  dummy  bit  is  stripped  off  by  the  telemetry  controller  to 
give  a  135  bit  sequence  for  transmission.  The  value?  of  the  error  array,  temperature, 
number  of  ensembles,  tilt  variability  and  heading  variability  are  the  same  for  both 
halves  of  the  array. 
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Figure  9:  A  schematic  of  the  DPM  test  configuration,  including  two  IBM  compatible 
PCs,  an  ammeter,  and  various  test  cables,  is  shown.  The  ammeter  replaces  the  DPM 
shorting  plug  and  is  used  to  check  current  draw  by  the  UART  and  microcontroller. 
The  PCs  simulate  the  ADCM  and  telemetry  controller.  The  ADCM  simulator  sends 
a  sequence  of  data  ensembles  designed  to  test  a  variety  of  DPM  error  checking 
features  to  the  DPM.  The  telemetry  simulator  interrogates  the  DPM  and  records 
the  output.  The  output  from  a  test  run  can  be  compared  to  the  desired  results  to 
confirm  proper  operation. 
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40R006217101FCFF020000FCFFOOFF0177776 
41R206217101FE00020000FFFFFFFFFF77776 
40R402218101FBFE0100FFFCFEFEFEFD77777 
41R60221810 1FD0 10000FFFCFFFCFEFD77776 
40R00  6216100FCFEFFFEFCFBFCFDFDFE87767 
41R206216100FD00FFFFFDFCFCFEFCFE77776 
40R406217101FBFDFFFCFDFBFD0QFDFF87777 
4 1R60  62 171 0 1FDFDFFFCFCFCFEFDFDFE7777  6 
40 RO 043 30 0000000000000000000000077777 
41 R2 043300000000000000000000000077777 
40R4 06217101 FE010100FF050707060487777 
41R60621710100020100FD060607060577766 
40R00221810101040 60 50 4060809070677776 
41R20221810103050 60 303080 908070977767 
40 R4 0221810102070 AO 806060909080577777 
41R602218 101050 90A08 07080 908080 677777 
40R002218 101020 90B0 907060909080677787 
4 1R2022 18 101070B0A0807090 908080877777 
40R402218202030BO 9090806080 9080637777 
4 1R602218202070A0A0A0 9080 8 09070577777 
40R002218 10 1050A0A0A0 904 060 60 60477777 
4 1R2022 18 10 1080A0A0A0 9060 605040477777 
40R4022 18 10 10607080A0 904 0705050477777 
4 1R6022 18 10107080 90 908070 60 6050477776 
40R0 0221820106070 90 BO AO 30507050577777 
41R20221820107080AOBOB04050 6040377777 
40R402218 101050 6070 90A010405030 377776 
4 1R602218101 07060 90A0 90304 0404027777 6 
40R002218 100020 40 60707010304050477777 
4 1R2022 18 1000304 060708030 4 04040477667 
40R4022181 0002 03040708030 304050477777 
4 1R6022 18 100030 4070607030 30 404037777 6 
40R0022 18 10 1030002050 604030 3030477777 
4 1R202218101FF0 10 40 60 50204 0404 0287776 
40R4 02218 10100FEFF0 302 06030 4050287777 
4 1R602218101FCFE0 10 30204 04 04040677776 


Figure  10:  The  expected  output  arrays  from  a  DPM  test  run  using  the  configuration 
shown  in  Fig.  9  and  the  data  file  DPMCCS6.BIN  as  input  to  the  OVERNITE.C 
program  are  shown.  Each  line  represents  the  response  of  the  DPM  to  an  interro¬ 
gation  from  the  PC  simulating  the  telemetry  controller.  Over  a  36  hr  interval  the 
144  ensembles  in  DPMCCS6.BIN  are  processed  into  IS  output  arrays  (there  are  36 
lines  since  the  array  is  output  one  half  at  a  time). 
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Table  1:  DPM  specifications 
12  July  1991 


Mechanical: 


Housing  Material 

-  6061-T6  Aluminum  Alloy 

-  Hardcoated,  Anode  protected 

Weight  in  air 

-  13  kg 

Weight  in  water 

-  6.6  kg 

*Length 

-  50.5  cm 

Diameter  (end  caps) 

-  14.6  cm 

(housing) 

-  14  cm 

Electrical  penetrators 

-  3 

(VSG-2BCL) 

-  (1  each) 

(XSG-3BCL) 

-  (1  each) 

(XSK-7BCL) 

-  (1  each) 

Pressure  Rating 

-  5000  db 

Electrical: 

Avg.  power  consumption 

-  15  mW 

Battery  capacity 

-  28  Ah  @  10.5  VDC 
(Alkaline) 

Controller 

-  Intel  87C51FC 

EPROM  (Internal) 

-  32  k 

RAM  (Internal) 

-  256  Bytes 

(External) 

-  32  k 

COM.  Ports 

-  2 

(EIA  -  485) 

-  ( 1  each) 

**  (EIA  -  423) 

-  (1  each) 

Features: 

-  Watchdog  Reset 

-  Isolated  EIA  423  Port 

-  Addressable 

-  Low  power  consumption 

-  Environmentally  tested 
from  50  to  —30  deg.  C 

*  Length  with  connectors  mated,  includes  anodes 
**  Optically  isolated,  configured  for  Simplex  operation 
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Table  2:  DPM  connector  &  cable  specifications 


Manufacturer  :  Brantner  L  Associates  Inc. 

1240  Vernon  Way 
El  Cajon,  CA  92020-1874 

DPM  Connectors 


Bulkhead  Connectors  :  XSK-7BCL,  1  each  (for  EIA-423  port) 
:  XSL-3BCL,  1  each  (for  EIA-485  port) 
:  VSG-2BCL,  1  each  (for  power  switch) 


Dummy  connector 
(for  shipping) 


RMK-7-FSD  w/locking  sleeve  K-FSL-P 
RMG-3-FSD  w/locking  sleeve  G-FSL-P 
VMG-2-FSD  w/locking  sleeve  G-FSL-P 


Shorting  connector  :  Speciiled  as  VMG-2-FSD  with  Pins  # 

1  and  2  Electrically  connected,  used 
with  locking  sleeve  P/N  G-FSL-P 


ADCP  -  DPM  Interconnecting  Cable  Assembly 


Cable  Terminations 

Cable  Length 
Cable  material 

Pressure  Rating 


XSL-20CCP 

RMK-7FS  (with  locking  sleeve  p/n  K-FLS-P) 
2  meters 

18/7-SO  (7  conductor,  #18  AWG  copper  wire, 
rubber  insulated,  with  neoprene  outer  jacket) 

20,000  psi  (mated) 


XSL-20CCP  Pin# 

XSK-7FS  Pin# 

2 

7 

4 

6 

5 

5 

13 

4 

14 

3 

15 

2 

16 

1 

Cable  Wiring 


Table  3:  DPM  parts  list 


ADCP  DATA  PROCESSING  MODULE 
Bill  of  Materials 

Item  Quantity  Reference 

Revised:  12  July  1991 

Part 

1 

3 

C1,C5,C12 

0.1  uF 

2 

2 

C2,C6 

10  uF 

3 

1 

C3 

1.0  uF 

4 

1 

C4 

100  uF 

5 

2 

C7,CS 

33  pF 

6 

1 

C9 

22  pF 

7 

2 

C10,C11 

18  pF 

8 

3 

D1,D2,D3 

1N5818 

9 

1 

D4 

MRD  821 

10 

1 

D5 

MLED  930 

11 

2 

D6.D9 

FD600 

12 

1 

D8 

1N4148 

*  13 

1 

Ll 

150  uH 

14 

3 

Q1,Q2,Q3 

2N3906 

15 

1 

Q4 

2N2222A 

16 

2 

R1,R3 

10.0  K 

17 

4 

R2,R5,R6,R12 

100  K 

18 

1 

R4 

1.0  M 

19 

1 

R6 

1.2  M 

20 

1 

R7 

499  K 

21 

2 

R7.R8 

5.6  M 

22 

1 

R9 

2.67  K 

23 

1 

RIO 

931 

24 

1 

Rll 

47  K 

25 

1 

U1 

87C51FC 

26 

1 

U2 

74HC573 

27 

1 

U3 

74  H  COO 

28 

1 

U4 

HM62256LP-15 

29 

1 

U5 

NSC858N-4I 

30 

1 

U6 

74HC4060 

31 

1 

U7 

MAX638AEPA 

32 

1 

U8 

HA5141-5 

33 

1 

U9 

LTC485IJ8 

34 

1 

Yl 

2.4576  Mhz 

35 

1 

Y2 

1.8432  Mhz 

*  Ll  was  constructed  by  using  39  turns  of  #30  AWG  enamel 
wire  and  a  Magnetics  Inc.  P/N  1 107CA100-3B7  ferrite  core. 
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